## Introduction

Last two posts on my blog were dedicated to Scrum Artifacts: [Product Backlog](/blog/scrum-artifacts-1-product-backlog/) and [Sprint Backlog](/blog/scrum-artifacts-2-sprint-backlog/). 

It’s time to talk about one of the Artifacts in Scrum which is the result of all actions in the [Sprint](/blog/scrum-events-1-the-sprint/) - **the Increment**.
 
![Increment](img/increment.png)

## What is the Increment?

Based on the Scrum Guide: 

>The Increment is the sum of all the Product Backlog items completed during a Sprint and the value of the increments of all previous Sprints. 

In other words, the Increment is the result of [Development Team’s](/blog/scrum-roles-1-development-team/) work in the [Sprint](/blog/scrum-events-1-the-sprint/). It’s the "Kinder Surprise" for stakeholders that can be unpacked and inspected during [Sprint Review](/blog/scrum-events-4-sprint-review/) meeting. That’s what everybody is waiting for!

## "DONE" Increment

Every new Increment needs to be "Done". It means that it needs to meet the Definition of "Done" created by the Scrum Team. 

The main role of the definition of "Done" is to increase and support high quality of the increment. Definition of "Done" is created by the [Development Team’s](https://letsscrumit.com/scrum-roles-1-development-team/) to have a common understanding about completed work and to ensure transparency.

What is more, definition of "Done" helps the [Development Team’s](https://letsscrumit.com/scrum-roles-1-development-team/) to select the right number of Product Backlog items into [Sprint Backlog](https://letsscrumit.com/scrum-artifacts-2-sprint-backlog/) during [Sprint Planning](https://letsscrumit.com/scrum-events-2-sprint-planning/) session.

![Done](img/done.jpg)

## Increment & Release

The increment doesn’t need to be released at the end of the Sprint, but it needs to be in releasable state.  It is important to create the increment that is in usable condition and can be released to the market. 

Why is it so important? Because it’s the best way to verify if a created product will fulfill users needs.That will show if the business goals are achieved and will give the a guidance to the Scrum Team what needs to be improved and why. Depending on the situation, [Product Owner](https://letsscrumit.com/scrum-roles-2-product-owner/) decides if it will be released or not.

## Summary
* Increment is sum of all items completed within the [Sprint](https://letsscrumit.com/scrum-events-1-the-sprint/)  + value of increments from previous iterations

* When Increment is created, definition of "Done" needs to be met - Decision about releasing the Increment is in the [Product Owner’s](https://letsscrumit.com/scrum-roles-2-product-owner/) hands, but it needs to be in useable/releasable state.

Find out what Increment is, how it is connected with the definition of "Done" and release.

Scrum Artifacts #3 The Increment

## Introduction

In my last post from Scrum Artifacts series, I described the king of artifacts in Scrum framework - [Product Backlog](/blog/scrum-artifacts-1-product-backlog/). Today I would like to tell you more about the next artifact - Sprint Backlog. 


## What is Sprint Backlog?

If Product Backlog is a king or queen of the Scrum Artifacts, Sprint Backlog can be called their beloved child. 

Based on the Scrum Guide: 

> The Sprint Backlog is the set of Product Backlog items selected for the Sprint, plus a plan for delivering the product Increment and realizing the Sprint Goal. 

## When & How the Sprint Backlog is created?

Sprint Backlog is created during the [Sprint Planning](/blog/scrum-events-2-sprint-planning/) session, when Scrum Team develops a plan for the Sprint and decides what can be "Done" during the upcoming iteration.

[Product Owner](/blog/scrum-roles-2-product-owner/) presents the business objectives and proposes Product Backlog items for the Sprint.

Then the Scrum Team starts discussion about functionalities and items that will be included in the Sprint.  Based on their expertise and skills, the [Development Team](https://letsscrumit.com/scrum-roles-1-development-team/) should decide what items can be “Done” in the next iteration and what work is required in order to achieve it. That’s how the Sprint Backlog is formed. 

## Sprint Backlog - transparency & commitment

Sprint Backlog is a great tool in Scrum that promotes transparency and supports commitment. 
First of all, [Development Team](https://letsscrumit.com/scrum-roles-1-development-team/) selects by themselves all items that will be "Done" during the Sprint. They commit to the work and decide how it will be done. They also own the Sprint Backlog and are responsible for managing their workload. It helps them to be fully committed. 

What is more, having a clear understanding of what needs to be done during the Sprint, promotes Transparency and minimizes understatements. 

Based on the Scrum Guide: > The Sprint Backlog makes visible all the work that the Development Team identifies as necessary to meet the [Sprint Goal](/blog/sprint-goal-why-do-we-need-it/).

The [Development Team](/blog/scrum-roles-1-development-team/) can be fully focused on their work, which increases the value of developed increment. 

![Transparency](img/transparency.jpg)

## Sprint Backlog & Continuous Improvement

During [Sprint Retrospective](/blog/scrum-events-5-sprint-retrospective/), Scrum Team should select at least one improvement and include it in the Sprint Backlog.

That’s the best approach to make sure that improvements discussed on the [Sprint Retrospective](/blog/scrum-events-5-sprint-retrospective/) are part of the Sprint.  It will create continuous improvement and help the [Development Team](/blog/scrum-roles-1-development-team/)  to become a high performance team.

## Sprint Backlog - Fully prescribed?

Initially when Sprint Backlog is created it contains enough details to be understood by the  [Development Team](/blog/scrum-roles-1-development-team/).

Does it mean that it is fully described and fixed? Definitely no. It is modified by the [Development Team](/blog/scrum-roles-1-development-team/) and emerges during the Sprint.  The team can discover that they need to adjust the plan, do some additional tasks or change their approach. 

It is important to mention that Sprint Backlog solely belongs to the [Development Team](/blog/scrum-roles-1-development-team/). It means that Sprint Backlog can be changed but only if [Development Team](/blog/scrum-roles-1-development-team/) needs to update it. It cannot be updated by [Product Owner](/blog/scrum-roles-2-product-owner/) or [Scrum Master](/blog/scrum-roles-3-scrum-master/).

The [Development Team](/blog/scrum-roles-1-development-team/) is committed to the work and they decide what changes are required. They can add new work if it is required in order to achieve the Sprint Goal or remove tasks that are no longer required. 

## Sprint Backlog & Daily Progress

During the Sprint the [Development Team](/blog/scrum-roles-1-development-team/) is responsible for tracking their work progress.  Sprint Backlog helps them to track total remaining work and inspect it on Daily Scrum.

Transparency of all work required in the Sprint gives the team possibility to plan their work daily and adapt if there are any changes in tasks required or impediments to be removed. 

![Progress](img/progress.jpg)

## Summary

The most important information about Sprint Backlog that you should remember from this post: 
* It is set of Product Backlog items selected for the Sprint plus delivery plan 

* Sprint Backlog is created during the [Sprint Planning](/blog/scrum-events-2-sprint-planning/) session 

* It promotes transparency and supports commitment 

* During Sprint Retrospective, at least one improvement should be selected and included in the Sprint Backlog. 

* Sprint Backlog solely belongs to the [Development Team](https://letsscrumit.com/scrum-roles-1-development-team/) 

* It can be adjusted during the Sprint by [Development Team](https://letsscrumit.com/scrum-roles-1-development-team/) 

* Sprint Backlog is a great tool for tracking of daily progress

What is Sprint Backlog? Who is responsible for managing it? How is it created? Jump in to find it out.

Scrum Artifacts #2 Sprint Backlog

## Introduction

There are multiple reasons why I created this blog. One of them is to help you to get the most important information about the [Scrum](/blog/first-steps-to-learn-scrum). Of course, you can do it by reading [Scrum Guide](https://scrumguides.org/scrum-guide.html), but you will not find there real-life examples.

In my last two series I described all Scrum events and Scrum roles. It’s time to explain Scrum artifacts. I’ve already mentioned them in my previous posts, but I would like to tell you more about them.

Let’s start from the king of the Scrum artifacts - **Product Backlog**.
FYI - this post has been updated as per [Scrum Guide](https://scrumguides.org/scrum-guide.html)2020.

## What is the Product Backlog?

Product Backlog is really the king, because none of these Scrum-related actions couldn’t happen without it. Imagine that you are baking a cake. You can do it without the recipe, but at least you need to know what ingredients are required for the cake. The Product Backlog is for the product, like a list of ingredients for a cake.

Based on the [Scrum Guide](https://scrumguides.org/scrum-guide.html):

> The Product Backlog is an emergent, ordered list of what is needed to improve the product. It is the single source of work undertaken by the Scrum Team.

## Single source of requirements

Why Product Backlog - the ordered list with all “ingredients” is such an important part of [Scrum](/blog/first-steps-to-learn-scrum)?

First of all, it is **one source of truth** that will tell you what is required for a product.
Have you ever experienced a situation when multiple people ask you for the same thing, but all of them have different requirements? Product Backlog as a list of items helps to gather all the requirements in one place and order them. It minimizes mistakes caused by conflicting requirements or lack of visibility of changes.

What is more, having a well-managed Product Backlog, supports **transparency** - one of three pillars of empiricism which is the foundation of the[Scrum](/blog/first-steps-to-learn-scrum).

![List](img/list.jpg "list")

## Who should manage the Product Backlog

There is one role in [Scrum](/blog/first-steps-to-learn-scrum) responsible for Product Backlog management - [Product Owner](/blog/scrum-roles-2-product-owner/). She or he should decide about the content, availability and order of the Product Backlog Items. [Product Owner](/blog/scrum-roles-2-product-owner/) needs to make sure that Product Backlog is visible and clear for everyone in the Scrum Team.

## Fixed requirements vs Product Backlog

In traditional project management all requirements are listed in the scope of work at the beginning of the project and they remain fixed.

Agile approach promotes different ways of working with the client and their needs. Initial requirements are listed in the Product Backlog, but the list evolves as the product and market situation evolves. It means that Product Backlog is a living artifact that is never complete.

Responding to change is more important in [Scrum](/blog/first-steps-to-learn-scrum) than following the plan. Why? Because everything related to the product can change: users, market situation, company strategy, even worldwide health issues like COVID19 can totally change the usability of the product. That’s why Product Backlog is dynamic and it exists as long as the product exists.

## Product Backlog - what does it contain?

We have this magic list - Product Backlog, but what can we find inside? The answer is: **everything related to the product.**

Based on the \[Scrum Guide] 2017](https://scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-US.pdf):

> The Product Backlog lists all features, functions, requirements, enhancements, and fixes that constitute the changes to be made to the product in future releases.

It is not included in the latest version of the guide. It helps to avoid narrowing down interpretation of Product Backlog.

There are multiple ways of expressing the Product Backlog. I will share with you the way I experienced it. In the list that one of my Scrum Team was using, below items were included:

* **Epic** - piece of functionality which can be done within multiple Sprints. It is the high level idea of the elements of a product.

Before I will jump in to describe others, I would like to mention that Epics (sometimes also features which I didn’t mention here) can be used to create “Sprint Roadmap” to have the high-level idea of the development of the product.

* **User Story** - it is the Product Backlog item which describes the specific need of the user. It should be large/small enough to be able to do it within one Sprint.
  It should contain:
  - Information about the user - who they are
  - Description of what the user would like to do, what are their needs
  - Explanation what is the purpose of their action
  Example of the above: As a (user), I want to (what user would like to do), so that I can (the purpose of the action).
  - Acceptance Criteria : everything that is required from the functionality from the user’s perspective.E.g. Given (context), When (action), Then (outcome). This is just an example. The most important is that criteria should explain what is specifically required in the story.
  - Size - estimated by the [Developers](/blog/scrum-roles-1-development-team/) on the [Sprint Planning](/blog/scrum-events-2-sprint-planning/).
* **Bug** - work item created, when there is some issue recognized in functionality.
* **Task** - There is possibility that there are some technical actions required for the product that do not fit into stories. There are teams who use tasks this way.
* **Sub-task** -  User stories can contain multiple smaller sub-tasks which need to be actioned , so that the story is “Done”. That’s the “How” created by [Developers](blog/scrum-roles-1-development-team/). They decide about everything that is required to make the story “Done”. Definition of "Done" is defined and used by them to recognize the status of the user story.

Above I gave you examples how you can describe the Product Backlog. But there are multiple ways to do it. Below I also added a few other Product Backlog items used by some teams.
Remember that your [Product Owner](/blog/scrum-roles-2-product-owner) & the whole Scrum Team decide what the Product backlog will look like. The most important thing is that it will help in delivering the value. 

![Product-Backlog](img/product-backlog.drawio-1-.png "Product backlog")

## Product Backlog Refinement

Once there are any changes required to the Product Backlog, the [Product Owner](/blog/scrum-roles-2-product-owner/) and [Development Team](/blog/scrum-roles-1-development-team/) meet to refine it. What does it mean? They can update some details, estimates or priority. They analyze user stories, collaborate and make all required changes.

As per [Scrum Guide 2017](https://scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-US.pdf): 

> Refinement usually consumes no more than 10% of the capacity of the Development Team.
> However, Product Backlog items can be updated at any time by the Product Owner or at the
> Product Owner’s discretion.

I0% is not mentioned in the latest version of the Scrum Guide. There is only information about treating refinement as an ongoing activity. 

## Product Backlog order

The items at the top of the Product Backlog should be the most detailed. The lower item is in order, the less detail is required. It means that Product Backlog doesn’t need to be fully specified, detailed to start the first Sprint. The only things that matter at that stage are the highest ordered items.

As per [Scrum Guide 2020](https://scrumguides.org/scrum-guide.html):

> Product Backlog items that can be Done by the Scrum Team within one Sprint are deemed ready for selection in a Sprint Planning event.

By "Ready" - they mean detailed enough for the [Developers](/blog/scrum-roles-1-development-team) to work on them.

![Order](img/order.jpg "Order")

## Summary

The most important information that you should remember from this post about **Product Backlog**:

* It is the **ordered list** that is the single source of everything that is needed for the product. 
* It is the **living artifact** that is updated wherever changes occur and it exists as long as the product exists.
* [Product Owner](/blog/scrum-roles-2-product-owner/) is responsible for managing the Product Backlog: content, order, priority etc.
* Product Backlog is **not fixed** - it is never complete.
* Product Backlog can contain for example: **Epic, User Story, Task, Bug**.
* Product Backlog **refinement** is done to update some details of the Product Backlog. 
* The highest ordered items in the Product Backlog should be more detailed to be "Ready" for the [Developers](/blog/scrum-roles-1-development-team) to start working on them.

The first post in the Scrum Artifacts series that will help you to understand better Product Backlog and its role in the Scrum.

3 posts tagged with #scrum artifacts